Allow linking a prebuilt optimized compiler-rt builtins library #143689

pmur · 2025-07-09T15:40:39Z

Extend the .optimized-compiler-builtins bootstrap option to accept a path to a prebuilt compiler-rt builtins library, and update compiler-builtins to enable optimized builtins without building compiler-rt builtins.

rustbot · 2025-07-09T15:40:46Z

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-07-09T15:40:48Z

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35

Kobzol · 2025-07-09T19:22:53Z

I don't really know much about the optimized compiler-rt builtins. Maybe @tgross35 might know more?

Mark-Simulacrum · 2025-07-09T22:54:33Z

Can you say more about how much time this saves? Historically it's been my impression locally that building is basically free, this flag is more about whether it's possible to build (e.g., needs to be off if you're ad-hoc cross compiling). Though maybe I'm remembering wrong?

pmur · 2025-07-10T14:34:10Z

Can you say more about how much time this saves? Historically it's been my impression locally that building is basically free, this flag is more about whether it's possible to build (e.g., needs to be off if you're ad-hoc cross compiling). Though maybe I'm remembering wrong?

The goal is to enable optimized compiler-builtins in fedora packaging. There, rust is built using the distro provided llvm and resulting libraries. Some runtime features are absent if optimized compiler-builtins are not used. Notably, outlined aarch64 LSE atomic operations are not available without this support.

cuviper · 2025-07-10T16:40:26Z

Right, it's less about time and more about wanting to use our existing system LLVM packages.

pmur · 2025-07-22T22:07:21Z

Ping @tgross35. The intent here is to enable optimized-builtins in Fedora using the system's compiler-rt.builtins library.

tgross35

The changes to compiler-builtins lgtm with a possible rename of the var, assuming you have verified this works locally. Somebody more familiar with bootstrap (@Kobzol?) will need to review the changes there.

src/bootstrap/src/core/build_steps/compile.rs

library/compiler-builtins/compiler-builtins/build.rs

pmur · 2025-07-28T20:47:40Z

The changes to compiler-builtins lgtm with a possible rename of the var, assuming you have verified this works locally. Somebody more familiar with bootstrap (@Kobzol?) will need to review the changes there.

I did test builds with the fedora targets (excepting s390x, it lacks a libcompiler-rt.builtins library in rawhide right now). Likewise, I verified the LSE support linked in for aarch64 does work.

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

tgross35 · 2025-08-01T06:29:30Z

library/compiler-builtins/compiler-builtins/build.rs

+            if let Some(dir) = rt_builtins_ext.parent() {
+                println!("cargo::rustc-link-search=native={}", dir.display());
+            }
+            println!(
+                "cargo::rustc-link-lib=static:+verbatim={}",
+                rt_builtins_ext.to_str().unwrap()
+            );


Does println!("cargo::rustc-link-arg={}", rt_builtins_ext.to_str().unwrap()) work to replace these by chance? I think passing the exact path to the linker should avoid needing to set both -l and -L.

That seems like it should work, but trying locally (x86-64-unknown-linux-gnu) didn't work as expected. The builtins library wasn't copied into the .rlib as is the case with the above or letting rust built them.

tgross35 · 2025-08-01T06:41:03Z

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

I think this can happen in niche build setups, but no special handling should be needed; all three libraries make their builtin symbols weak, so conflicts aren't a problem.

bors · 2025-08-01T14:45:20Z

☔ The latest upstream changes (presumably #144773) made this pull request unmergeable. Please resolve the merge conflicts.

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? `@tgross35`

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ``@tgross35``

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ```@tgross35```

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ````@tgross35````

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? `````@tgross35`````

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ``````@tgross35``````

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ```````@tgross35```````

Rollup merge of #144705 - pmur:murp/aarch64-lse, r=Amanieu compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for #143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ```````@tgross35```````

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang/rust#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ```````@tgross35```````

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled. Enabling LSE is the primary motivator for rust-lang#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE. r? ```````@tgross35```````

pmur · 2025-08-12T17:31:36Z

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

I think this can happen in niche build setups, but no special handling should be needed; all three libraries make their builtin symbols weak, so conflicts aren't a problem.

The rust versions are weak, I am not sure the library built by optimized-compiler-builtins or the system provided libclang_rt.builtins.a exposes weak builtin functions. When I tried explicitly linking a second time on aarch64, it raised errors.

pmur · 2025-08-19T15:12:43Z

@tgross35 ping, are there any more changes needed for this patch?

tgross35 · 2025-08-19T21:52:21Z

I was just waiting for somebody from bootstrap to +1 the changes there, @rust-lang/bootstrap would anybody mind taking a look?

I guess it would probably wouldn't be a bad idea to at least mention this (and the other config) in library/compiler-builtins/compiler-builtins/README.md, if you don't mind adding something simple like:

## Configuration

`compiler-builtins` can be configured via the following environment variables:

- `LLVM_COMPILER_RT_LIB`
- `RUST_COMPILER_RT_ROOT `

See `build.rs` for details.

## Contributing
...

Kobzol

I took a look. Fine with the approach in general, but I'd appreciate two changes:

It would be more consistent if also the build.optimized-compiler-builtins option took a path, so that we don't have the same named option that takes different values in build and in the target config.
It would be nicer to create an enum, e.g. CompilerBuiltinsConfig, which would have two variants (Build and UseExisting(PathBuf)) and parse this enum from the TOML config files immediately, and then work with it in bootstrap, rather than converting the typed in optimized_compiler_builtins. That would also allow us to have only a single function in Config, and wouldn't require creating optimized_compiler_builtins_path.

bootstrap.example.toml

Kobzol

Thank you, I think it's much easier to understand now! I'd appreciate some small comment changes, but other than that LGTM.

src/bootstrap/src/core/config/config.rs

src/bootstrap/src/core/config/mod.rs

Kobzol

Since this changes config options, you could also add a change entry to change_tracker.rs, but this is probably so niche that it's not even needed.

LGTM from my side.

Extend the <target>.optimized-compiler-builtins bootstrap option to accept a path to a prebuilt compiler-rt builtins library, and update compiler-builtins to enable optimized builtins without building compiler-rt builtins.

Create a dedicated enum to abstract the different ways compiler-builtins can be configured. This also relaxes build.optimized-compiler-builtins to accept the path of a library to match the behavior of <target>.optimized-compiler-builtins override.

rustbot · 2025-08-20T20:22:13Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

pmur · 2025-08-20T20:34:22Z

Thanks. I also tried to improve the documentation in bootstrap.example.toml too.

rustbot assigned Kobzol Jul 9, 2025

This comment has been minimized.

Sign in to view

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from 27fcb13 to 1ea1789 Compare July 9, 2025 18:29

tgross35 self-assigned this Jul 9, 2025

cuviper mentioned this pull request Jul 10, 2025

Don't panic if WASI_SDK_PATH not set when detecting compiler #143752

Merged

tgross35 reviewed Jul 23, 2025

View reviewed changes

src/bootstrap/src/core/build_steps/compile.rs Outdated Show resolved Hide resolved

library/compiler-builtins/compiler-builtins/build.rs Outdated Show resolved Hide resolved

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from 1ea1789 to 8ce8e15 Compare July 24, 2025 16:20

pmur mentioned this pull request Jul 30, 2025

compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled #144705

Merged

tgross35 reviewed Aug 1, 2025

View reviewed changes

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from 8ce8e15 to f8de502 Compare August 4, 2025 21:23

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from f8de502 to b382478 Compare August 12, 2025 17:14

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from b382478 to 1b5dd10 Compare August 19, 2025 22:09

Kobzol requested changes Aug 20, 2025

View reviewed changes

bootstrap.example.toml Outdated Show resolved Hide resolved

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 20, 2025

Kobzol reviewed Aug 20, 2025

View reviewed changes

src/bootstrap/src/core/config/config.rs Outdated Show resolved Hide resolved

src/bootstrap/src/core/config/mod.rs Show resolved Hide resolved

This comment has been minimized.

Sign in to view

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from 118d8d0 to 1a868a3 Compare August 20, 2025 18:47

Kobzol approved these changes Aug 20, 2025

View reviewed changes

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from 1a868a3 to ad333e4 Compare August 20, 2025 20:10

Paul Murphy and others added 2 commits August 20, 2025 15:20

Allow linking a prebuilt optimized compiler-rt builtins library

dec22b6

Extend the <target>.optimized-compiler-builtins bootstrap option to accept a path to a prebuilt compiler-rt builtins library, and update compiler-builtins to enable optimized builtins without building compiler-rt builtins.

pmur force-pushed the murp/external-rt-optimized-compiler-builtins branch from ad333e4 to 12172b6 Compare August 20, 2025 20:22

Allow linking a prebuilt optimized compiler-rt builtins library #143689

Are you sure you want to change the base?

Allow linking a prebuilt optimized compiler-rt builtins library #143689

Uh oh!

Conversation

pmur commented Jul 9, 2025

Uh oh!

rustbot commented Jul 9, 2025

Uh oh!

rustbot commented Jul 9, 2025

Uh oh!

This comment has been minimized.

Kobzol commented Jul 9, 2025

Uh oh!

Mark-Simulacrum commented Jul 9, 2025

Uh oh!

pmur commented Jul 10, 2025

Uh oh!

cuviper commented Jul 10, 2025

Uh oh!

pmur commented Jul 22, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

pmur commented Jul 28, 2025

Uh oh!

tgross35 Aug 1, 2025

Choose a reason for hiding this comment

Uh oh!

pmur Aug 4, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Aug 1, 2025

Uh oh!

bors commented Aug 1, 2025

Uh oh!

pmur commented Aug 12, 2025

Uh oh!

pmur commented Aug 19, 2025

Uh oh!

tgross35 commented Aug 19, 2025

Uh oh!

Kobzol left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Kobzol left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Kobzol left a comment

Choose a reason for hiding this comment

Uh oh!

rustbot commented Aug 20, 2025

Uh oh!

pmur commented Aug 20, 2025

Uh oh!

Uh oh!